Subject: (Fwd) Re: Timestamps in MIBs

From: "Bill Kwan" <[email-masked]>
Date: Tue, 21 Nov 1995 10:30:27 EST5EDT

Hi folks,

I apologize for this  long e-mail on multiple mailing lists, but I believe the 
topic is applicable to all of these mailing lists. The following are the 
discussions we had been having with Kaj (with input from  Keith McCloghrie) on
the subject of timestamps. BobM and I sent Kaj and Deirdre a description of the 
problem and asked for their advise. I have attached Kaj's response plus some 
followup questions and the original message. I think this e-mail should be 
self-explanatory. Based on this feedback, we need to decide how we want to 
handle the timestamp issue.

Regards,
Bill
------- Forwarded Message Follows -------
Date:          Mon, 20 Nov 95 19:33:15 EST
To:            "Bill Kwan" <[email-masked]>,
               "R.E. (Robert) Moore (254-4436)" <[email-masked]>
From:          Kaj Tesink <[email-masked]>
Subject:       Re: Timestamps in MIBs
Cc:            [email-masked] (Deirdre Kostick), [email-masked]

there is no generic solution and
i havent enough background in your particular problem, but:
- relying fully on sysUpTime should be possible but may put additional
  requirements on the implementation (not necessarily
  visible in a MIB)
- by not fully relying on sysUpTime you would still need to
  address the issue of different clocksources as Keith pointed out

thus, it seems you need to do some work on identifying the exact
problem and see how above two points can be accommodated.

kaj

At 11:47 AM 11/17/95 EST5EDT, Bill Kwan wrote:
>Kaj and Keith,
>
>Thank you for your timely response to our questions. I understand the concerns
>for alternate timestamping (so did we, which is why we bought it up), but
>I need some clarifications. I am somewhat confused as to what you are suggesting
>we do.  My sense is that neither of you felt we have presented a strong enough 
>case to come up with an alternate timestamping (which is fine). But it sounds to
>me like it is a known issue  that have came up before. How have other MIBs 
>handle it? Have they ignored it and should we do the same? Or is there a way
>to solve these problem in the MIB? 
>
>Thanks again for all your help.
>
>Regards,
>Bill
>
>> Date:          Fri, 17 Nov 95 11:13:59 EST
>> To:            "Bill Kwan" <[email-masked]>,
>>                "R.E. (Robert) Moore (254-4436)" <[email-masked]>
>> From:          Kaj Tesink <[email-masked]>
>> Subject:       Re: Timestamps in MIBs
>> Cc:            [email-masked], [email-masked] (Deirdre Kostick),
>>                [email-masked]
>
>> Bill and Bob,
>> 
>> Thanks for pointing this issue out. I had indeed not spotted it in the
>> previous MIB review.  This is an interesting issue that I think has popped
>> up in the past. My immediate intuitive reaction was: dont come up with
>> alternative timestamping when not absolutely needed. I shared this issue
>> with Keith as well who concurred and responded with some more technical
>> arguments against alternative times ampting. His observations are attached.
>> In summary I suggest that you revisit this issue. Hope this helps,
>> 
>> kaj
>> 
>> At 11:35 AM 11/16/95 EST5EDT, Bill Kwan wrote:
>> >Kaj and Deirdre,
>> >
>> >One last major issue remains for the APPC MIB that has just come up regarding
>> >timestamps. I have attached  a long description of the problem, but I will try 
>> >to summarize it. Earlier in the discussion of the APPC MIB (and DLSw MIB),
>> >an issue was bought by IBM that the traditional way of implementing 
>> >timestamps by using sysUpTime is not always possible. The agent or sub-agent 
>> >implementing the MIB may not always have access to sysUpTime for a 
>> >variety of potential reasons (including a distributed agent environment). IBM
>> >has implemented an alternative in their products to create a MIB specific 
>> >timestamp that is relative to the UpTime of the agent that implements the
>> >MIB. It was suggested and agreed upon by the working group (and the DLSw 
>> >MIB working group). In fact, the APPC MIB drafts that were reviewed by
>> >Kaj had those particular MIB-specific timestamps. We assumed this was 
>> >acceptable since Kaj did not mentioned it in his review (he might have just 
>> >missed it).
>> >
>> >Most recently at the AIW meeting, someone from BNR raised the issue of 
>> >whether this private timestamping was acceptable. Discussions went back and
>> >forth and finally a compromise was agreed upon at the meeting to support both
>> >methods (see details). Further discussions bought up the issue of how strongly
>> >we want to favor one method vs the other in our description. 
>> >
>> >The bottom line is what should we do as regard to the APPC MIB? 
>> >Should we 
>> >
>> >1) Go with what we have today (a MIB-centric timestamp).
>> >2) Go back to using sysUpTime.
>> >3) Go with the compromise proposed.
>> >4) or something else.
>> >
>> >I am trying to get a concensus, but would very much like to hear your opinions 
>> >on this subject. The other issue that is making this tougher is that the other 
>> >SNA-oriented MIBs (especially DLSw)  are waiting to see what we do in the
>> >APPC MIB  so that they can follow suit. So I want to make sure we make the
>> >"right" decision. Thanks.
>> >
>> >Regards,
>> >Bill
>> >
>> ------------------------------------------------------
>> 
>> Return-Path: <[email-masked]@mail.bellcore.com>
>> X-Station-Sent-From: eve.bellcore.com
>> From: Keith McCloghrie <[email-masked]>
>> Subject: Re: Timestamps in MIBs
>> To: [email-masked] (Kaj Tesink)
>> Date: Fri, 17 Nov 95 1:11:16 PST
>> Cc: [email-masked]
>> 
>> Kaj,
>> 
>> I too am uncomfortable with this proposal.  It is not so much a matter
>> of timestamps, but rather of clock sources from which timestamps are
>> taken.
>> 
>> > I was wondering whether you have some insights on this one.
>> > Here are a couple of my own observations:
>> > - alternative options are bad
>> 
>> Agreed.
>> 
>> > - while these folks havent spelled out their exact
>> >   problems with sysUpTime i think they may have a case
>> >   (e.g., proxy situations)
>> 
>> It seems to me that their whole argument is that some agents are
>> implemented in a manner such that parts of that agent cannot get access
>> to the agent's (global) value of sysUpTime.  Comments that such agents
>> will not comply with the standard unless it's changed are irrelevant.
>> I also suggest that saying existing distributed agent APIs are incomplete
>> and therefore the standrad needs to be changed is also bogus.
>> 
>> The two common examples of such distributed agents are proxy agents, and
>> agents consisting of a master agent and one or more subagents.  In both
>> of these cases, the division between what information is available from
>> one part of the agent versus from some other parts is NOT necessarily
>> along MIB module boundaries.  For example, in an application MIB, one
>> sub-agent may provide information on some applications, and another
>> sub-agent may provide info on others, where information on all applications
>> is defined in the same application MIB.  Their "solution" does not solve
>> the "problem" in such a case.
>> 
>> > - they may have overlooked the DateAndTime TC
>>  
>> Indeed, use of DateAndTime implies an additional clock source (a time of
>> day clock) in addition to sysUpTime.  But what if two parts of an agent
>> used different Time-of-day clocks, and thus, their DateAndTime values
>> were not synchronized.
>> 
>> I suggest they need a lot more thought on the scope of the problem
>> they are trying to solve.
>> 
>> Keith.
>> 
>> > >------- Forwarded Message Follows -------
>> > >Date:          Wed, 15 Nov 95 09:40:11 EST
>> > >From:          "R.E. (Robert) Moore (254-4436)" <[email-masked]>
>> > >To:            [email-masked]
>> > >Subject:       Time stamp alternatives in SNMP MIBs
>> > >
>> > >Bill,
>> > >
>> > >You asked that I provide a write-up of the time stamp alternatives we've
>> > >been discussing since AIW 9, for you to forward to Kaj and Deirdre.  Here
>> > >goes:
>> > >
>> > >SNMP MIBs require objects that return time stamps for certain events of
>> > >interest to a Management Station.  Two examples:
>> > >
>> > >   -  When the MIB is used to log data associated with an exceptional
>> > >      event (e.g., failure of a link or an SNA session), the time stamp
>> > >      indicates when the event occurred.
>> > >
>> > >   -  When there's a need to reduce a Management Station's burden in
>> > >      polling the objects in a MIB group or table, an object can be
>> > >      defined to return the time when an object in the group or table
>> > >      last changed.  A Management Station can then poll this one object,
>> > >      and know that until its value changes, the last values it got for
>> > >      the objects in the group or table are still valid.
>> > >
>> > >Early in its history SNMP decided to use a relative time for these time
>> > >stamps, rather than something like GeneralizedTime.  This decision led to
>> > >the object sysUpTime, and the corresponding textual convention TimeStamp.
>> > >
>> > >The question we've been discussing is whether our MIBs (APPC, APPN, DLSw)
>> > >should index their time stamp objects to sysUpTime, versus indexing them
>> > >to the time that the portion of the agent system corresponding to the
>> > >functionality represented by their specific MIB modules was last re-
>> > >initialized.  For brevity, let me call the first of these approaches
>> > >sysUpTime-centric time stamping, and the second one MIB-centric time
>> > >stamping.
>> > >
>> > >The following arguments have been offered in favor of sysUpTime-centric
>> > >time stamping:
>> > >
>> > >1.  It's how all other SNMP MIBs have done their time stamping, and
>> > >    there's no valid reason to change now.
>> > >
>> > >2.  It greatly simplifies a management application's task of relating
>> > >    events from one MIB with events from another MIB.  If, for example, a
>> > >    management application can, by simply comparing the objects of type
>> > >    TimeStamp in two MIB-based "log records," determine that an SNA
>> > >    session went down immediately after an LLC connection failed, this
>> > >    goes a long way towards establishing a causal connection between the
>> > >    two events.
>> > >
>> > >3.  Agent implementations that find it difficult or impossible to provide
>> > >    sysUpTime-centric time stamps are somehow substandard / kludgy /
>> > >    defective.
>> > >
>> > >The following arguments have been offered in favor of MIB-centric time
>> > >stamping:
>> > >
>> > >1.  Implementation experience has shown that there can be a number of
>> > >    perfectly legitimate reasons why (i) the portion of an agent system
>> > >    that implements support for a given MIB may not have access to
>> > >    sysUpTime, and/or (ii) even if it does have access to it, time stamps
>> > >    indexed to sysUpTime may be *less* valuable than ones indexed to the
>> > >    time that that portion of the agent was last re-initialized.
>> > >
>> > >    Among these arguments:
>> > >
>> > >       a.  Distributed environments:  "main" agent and MIB
>> > >           instrumentation running on different processors, with
>> > >           different clocks.
>> > >
>> > >       b.  Commercially available SNMP agent packages that do not provide
>> > >           sysUpTime across their subagent API.
>> > >
>> > >       c.  Re-initialization of "main" agent without re-initialization of
>> > >           MIB instrumentation, and vice versa.  What will happen to
>> > >           "last changed" objects in these cases, and what conclusion
>> > >           will a Management Station draw?
>> > >
>> > >       d.  Existing implementations where MIB-centric time stamps are
>> > >           more reliable than sysUpTime-centric ones, because the latter
>> > >           are derived from the time-of-day clock, and will give the
>> > >           wrong answer when the clock is reset.
>> > >
>> > >2.  The problems surrounding sysUpTime-centric time stamping are *not*
>> > >    unique to SNA and related MIBs:  they can potentially arise when
>> > >    someone implements the instrumentation for any SNMP MIB.  Thus it
>> > >    will be valuable to the SNMP community as a whole to come up with a
>> > >    general solution.
>> > >
>> > >3.  It benefits no one to ignore the difficulties listed here under
>> > >    1a - 1d, and pretend (or mandate) that all time stamping is
>> > >    sysUpTime-centric.  Some agents still won't implement
>> > >    sysUpTime-centric time stamping, because they can't.  Thus the two
>> > >    alternatives are really these:
>> > >
>> > >       a.  The MIBs sanction only the sysUpTime-centric paradigm for time
>> > >           stamping, but some agents do the MIB-centric one anyway,
>> > >           because it's all they can do.  In this case a management
>> > >           application has no way of telling which agents have used which
>> > >           paradigm, because all of their time stamps have the same type:
>> > >           TimeStamp
>> > >
>> > >       b.  The MIBs recognize both paradigms, and provide a management
>> > >           application with an easy, reliable way of telling which time-
>> > >           stamping paradigm a given implementation has used.  The
>> > >           application can then do whatever conversions are necessary to
>> > >           make the various time stamps it has retrieved significant
>> > >           relative to each other.
>> > >
>> > >    The argument is that given these two alternatives, b is clearly
>> > >    preferable to a, so recognizing only sysUpTime-centric time stamping
>> > >    in a MIB will actually make life *harder* for management
>> > >    applications, not easier.
>> > >
>> > >At this point I think it's accurate to say that the SNA NAU MIBs WG, the
>> > >AIW APPN / HPR MIBs SIG, and the IET DLSw MIB WG are all in agreement
>> > >that their respective MIBs should recognize both types of time stamping.
>> > >A somewhat secondary issue is still under discussion:  whether the two
>> > >types of time stamping should be presented
>> > >
>> > >   -  as equal alternatives, where an implementation is free to choose
>> > >      whichever one makes the most sense in its particular environment
>> > >
>> > >   -  as a preferred alternative (sysUpTime-centric) and a less preferred
>> > >      one (MIB-centric).
>> > >
>> > >The argument in favor of the second answer here is that since a
>> > >management application will always be converting MIB-centric time stamps
>> > >to sysUpTime-centric ones, we should try to get as many agent
>> > >implementations as possible to send sysUpTime-centric time stamps in the
>> > >first place.  The counter-argument is that if we put too many negative
>> > >adjectives on the MIB-centric alternative, implementations will be likely
>> > >to claim to do sysUpTime-centric time stamping when they really don't,
>> > >and we'll be back to the situation where a management application can't
>> > >tell how to interpret a particular agent's time stamps.
>> > >
>> > >My note from November 9 contains the definitions for the alternative
>> > >where sysUpTime-centric time stamping is preferred over MIB-centric.  The
>> > >objects would be the same, but the wording would change somewhat for the
>> > >alternative where both types of time stamping are given equal status.
>> > >
>> > >Bill, let me know if you need something more from me now.
>> > >
>> > >Regards,
>> > >Bob